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Abstract 

In order to alleviate the inefficiencies caused by the interaction of the logic and functional sides, 
integrated languages may take advantage of demand information — i.e. knowing in advance which 
computations are needed and, to which extent, in a particular context. This work studies demand 
analysis - which is closely related to backwards strictness analysis - in a semantic framework of 
partial predicates, which in turn are constructive realizations of ideals in a domain. This will allow 
us to give a concise, unified presentation of demand analysis, to relate it to other analyses based on 
abstract interpretation or strictness logics, some hints for the implementation, and, more important, 
to prove the soundness of our analysis based on demand equations. There are also some innovative 
results. One of them is that a set constraint-based analysis has been derived in a stepwise manner 
using ideas taken from the area of program transformation. The other one is the possibility of using 
program transformation itself to perform the analysis, specially in those domains of properties where 
algorithms based on constraint solving are too weak. 

KEYWORDS: functional-logic programming, demand analysis, strictness analysis, program transfor- 
mation, abstract interpretation, set-constraint analysis 



1 Introduction 

Although the main idea of declarative programming is to use mathematical elements for 
programming, the area is split in two main paradigms based on the subset of mathematics 
they are focused on: functional programming (functions: lambda calculus) and logic pro- 
gramming (predicate logic). However it is obvious that both paradigms have a common 
core and can be seen as different faces of a single idea. 

Functional-logic languages aim at bringing together the advantages of functional pro- 
gramming and logic programming, see ( Hanus 19,94 . Moreno-N avarro 1994) , i.e. from 
functional programming they take higher-order features, polymorphic types, lazy eval- 
uation, etc., while logic programming provides partial information, constraints, logical 
variables, search, etc. The language CuiTy (IHanus et al. 2003 1 is the de facto standard of 
functional-logic languages. 

Probably, the combination of the last mentioned features of each paradigm (laziness, 
search) seems the more problematic to achieve in an efficient implementation. In other 

* This is the extended version of a paper accepted for publication in a forthcoming special issue of Theory and 
Practice of Logic Programming on Multiparadigm and Constraint Programming (Falaschi and Maher, eds.) 
Appendices are missing in the printed version. 
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words, for executing a program it may be necessary to evaluate a functional-like expression 
containing uninstantiated (i.e. existentially quantified) logic variables. 

The operational principle proposed for this situation is narrowing. Roughly speaking, 
narrowing guesses an instantiation for these variables. Functional nesting, nondeterminism, 
semantic unification, functional inversion, and lazy evaluation, which are key part for the 
expressiveness of functional-logic programs, are supported by this operational mechanism. 
In order to apply the general idea of narrowing to functional-logic languages, a functional- 
logic program is considered as a set of rewrite rules (plus some additional restrictions 
described later). 

However, narrowing by itself is not enough: a brute-force approach to finding all the so- 
lutions would attempt to unify each rule with each nonvariable subterm of the given equa- 
tion in every narrowing step. Even for small programs a huge search space would result. 
Therefore, an additional aspect to take into account in the implementation of functional- 
logic languages is the definition of an appropriate narrowing strategy. This strategy should 
be sound (i.e., only correct solutions are computed) and complete (i.e., all solutions or 
more general representatives of all solutions are computed). 

Many narrowing strategies for limiting the size of the search space have been pro- 
posed, but we are interested on those with a lazy behaviour. To preserve completeness, 
see ( |Moreno-Navarro and Rodriguez- Artalejo 1992| , a lazy narrowing step is applied at 
outermost positions with the exception that inner arguments of a function are evaluated, by 
narrowing them to their head normal forms, if their values are required for an outermost 
narrowing step. This property can only be ensured by looking-ahead on the rules tried in 
following steps. Unfortunately, a potentially infinite number of substitutions could arise 
but, in the case of inductively sequential programs it is possible to compute the property 
in an efficient way. This is the idea of needed narrowing introduced in ( |Antoy et al. 2000| . 
The paper also proves completeness and optimality of the strategy. 

But beyond this remarkable contribution to the implementation of functional-logic lan- 
guages two problems remain: (i) the strategy is optimal with respect to the length of deriva- 
tions but not in the size of the search space and additional improvements could be achieved, 
and (ii) it is defined only for a restricted class of programs (inductively sequential). 

1.1 Demand analysis 

Our proposal is to use a static analysis to improve the look-ahead approach. The analysis is 
able to extract demand information from a functional-logic program. This information can 
be used to guide and improve needed narrowing (thus cuting the search space and avoid- 
ing reevaluations). Additionally, we have some other advantages: transform nonsequential 
programs into sequential ones, following the ideas of (Marino and Moreno-Navarro 2000) 
where strictness analysis is used; safe replacement of strict equality by unification; im- 
plementation of default rules (Moreno-Navarro 1996); improvement of the accuracy of 
groundness analysis; translation into Prolog (Mariiio and Moreno-Navarro 1992.|Mariiioand Rey 1998) , 
etc. 

Demand analysis was introduced in (Marino and Moreno-Navarro 19921 and then used 
in (IMoreno-Navarro et al. 19931 IMarifio and Herranz 1993. .Marino et al. 1993 J as a way 
to improve the compilation of functional-logic programs. The essential idea was to per- 
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form backwards strictness analysis. The proposed solution consisted in generating, for a 
given program, a set of so called demand equations that were solved in a domain of regular 
trees {demand patterns). A strong point of demand patterns compared to existing strict- 
ness analyzers based on abstract interpretation was that they allowed, at least theoretically, 
inference in an infinite domain of properties. 

The aim of this paper is to provide a semantic framework {partial predicates) for de- 
mand analysis, to prove the correctness of demand equations and to introduce a novel 
approach to the implementation of analyzers. In fact, the whole process is simplified and 
optimized: while it is easier to reason about demand analysis with partial predicates, the 
implementation is also simpler because we can reuse a lot of work already done in partial 
evaluation tools. Moreover, we claim that the method can be applied to different contexts 
with a similar success. 

Partial predicates can be used to specify demand analysis as well as other classical anal- 
yses. One of the important point of this formalism is that it can be expressed by functional- 
logic programs. This has important consequences, allowing for reasoning about demand 
properties (for instance checking and inference of them) by using program transformation 
techniques. 

Applications of demand analysis go beyond the usual applications of strictness analysis 
in functional programming, where strictness is used for trying to provide bigger compu- 
tations that can be computed eagerly. Advances on this subject can have effects in getting 
a more efficient low level implementation, and in making easier and profitable the paral- 
lelization of programs. In functional-logic programming the gain in effiency means that 
some computations are not reevaluated or even that a wider class of programs can be used. 

The Reevaluation Problem. There is an efficiency problem caused by the interaction of 
laziness and backtracking which are, in some sense, antagonistic in nature. The former 
tries to delay some computations while the second drives different computations through a 
tree of branching paths. The problem appears clear - if we place some computation beyond 
the branching point there exists the risk that the evaluation may be performed several times. 
This can be rather annoying, because laziness is intended to save work, not to waste it. 

The toy example in Figure ^ shows how combining lazy evaluation and backtracking 
can lead to the repeated evaluation of delayed redexes. Observe that the redex (not True) 
is needed for the final result but, due to the outermost reduction strategy, its evaluation 
is delayed and evaluated twice, in different branches of the search tree. In this simple 
example, this is not serious, but in general, the redex reevaluated could have an expensive 
operation and the reevaluation can take place not only two, but an unbounded (even infinite) 
number of times. 

Sequentiality Analysis. One of the stages in compiling the code for a function definition in 
a lazy language is to decide (i) which arguments need reduction to perform the matching 
against the patterns in the left hand sides of the rules, and (ii) in which order are these 
arguments to be reduced. For instance, the code for the greater or equal predicate (Figure|2j 
needs to obtain a topmost data constructor for the second argument in order to choose a 
rule. If this constructor is Zero, the only match is with the first rule and no evaluation is 
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not False = True 
not True = False 

£ X False = not x 
£ X True = x 

?- £ (not True) (not y) 
Fig. 1. Reevaluation example. 



[f^(not True) (not y)| 
y=False,„.---^ ^^^^^True 



|£ (not True) True 
I 

|not(not True)] 



|£ (not True) False) 



(not True) 



not False 



iFalse 



[True I 



X >= y 

X >= (Succ y) 

Zero >= (Succ y) 
I 

False 

Fig. 2. Sample definition and its associated definitional tree. 



(>=) : : Nat -> Nat -> Bool 

X >= Zero 
m >= Zero = True | 

Zero >= (Succ n) = False True 

(Succ m) >= (Succ n) = m >= n 



(Succ x) >= (Succ y) 
I 

X >= y 



needed on the first argument, but if it is Succ, the first argument needs to be examined in 
order to choose between the second and third rules. 

Sloth' f Ma rino and Rey 1998> , our implementation of Curry, uses definitional trees ( |Antoy et al. 2000^ 
as the intermediate structure to store these decisions. Figure|2shows the definition for (>=) 
and the definitional tree obtained from it. Underlined positions are those where the branch- 
ing of the decisions are done. Next section will provide a definition of this concept but the 
graphical notation could be enough at this point. Observe that arguments are not necessar- 
ily examined in a left to right order. 

Sometimes, it is difficult - or impossible - to discover a definitional tree from the left 
hand sides alone. A typical example is the merging of two sorted lists: 

merge : : [Nat] -> [Nat] -> [Nat] 

merge [] ys = ys merge (x:xs) (y:ys) | x <= y = x: (merge xs (y:ys)) 

merge xs [] = xs I x >= y = y: (merge (x:xs) ys) 

If we just look at the left hand sides there is no way of building a decision tree like the 
one for (>=), but looking at the right hand sides we immediately see that both arguments 
to merge are demanded. A programmer would write, in fact, a modified version where the 
second rule is rewritten as 

merge (x:xs) [] = x:xs 

instead. In our paper JMarino and Moreno-Navarro 2000> we show that for the vast ma- 
jority of programs, the information obtained from type inference and demand analysis can 
help a compiler to generate sequential definitional trees for programs even when they are 
not syntactically sequential. 
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Avoiding Redundant Tests in Target Code. A substantial part of the overhead in implement- 
ing a lazy functional-logic language is precisely due to the code that implements the lazy 
evaluation of arguments (this was, in fact, what motivated research on strictness analysis 
of functional programs in the first place). This is particularly evident when looking at the 
translation scheme into Prolog of Sloth ( |Marino and Rey 1998^ , but the problem appears 
also in abstract machine based implementations. 

Demand information can help to generate, for most functions, eager code, with a drastic 
effect on efficiency. In the case of the translator to Prolog, this allows an almost verbatim 
translation with very httle overhead. 

Relation with Freeness and Sharing Analysis. Freeness and sharing ( [Jacobs and Langen 1992| 
[Muthukumar and Hermenegildo 1991) are two operational properties of logic programs 
which have been extensively studied. Freeness analysis can tell whether a free variable 
present in a goal does not get bound during its evaluation. Sharing analysis can tell whether 
two variables present in a goal will not eventually share some structure. Freeness and shar- 
ing are important, for instance, for the parallel execution of logic programs. Moreover, 
freeness can be useful to detect deterministic computations in functional-logic programs. 

Freeness and sharing are much more difficult to study in a lazy functional-logic language 
than in Prolog. From an operational point of view, the techniques used for Prolog can 
predict whether a given expression may bind some variables provided that this expression 
gets actually evaluated. 

From a denotational point of view, this connection can be explained because the lazy 
semantics can be seen as a restricted form of free-variable semantics where all variables 
are collapsed into one symbol (±). In this setting, variable propagation (freeness) and ±- 
propagation (strictness) share a common mechanism JMarino 2002t . 

Transformation of Strict Equality into Unification. The behaviour of the equality operator 
is slightly different in logic programming and in functional-logic programming. While in 
the first case the expression x-t, where x is a free variable, can be dealt with by assigning 
tXo X (provided that x does not occur in f), in functional-logic programming it is necessary 
to ensure that t can be evaluated to a total value, i.e. a term with no undefined subterms, 
otherwise the whole expression will be undefined. When logic programs are translated 
into functional-logic programs, this has two undesired effects: the expression cannot be 
resolved in constant time - which precludes the use of Prolog techniques such as difference 
lists - and the computed answers can be unnecessarily detailed. 

The connection with strictness is twofold. On one hand, totality is a much stronger con- 
dition than not being undefined, which makes rules with equality expressions a source of 
useful information for a strictness analyzer. On the other hand, the same techniques em- 
ployed to avoid redundant tests when applying strictness analysis can be used to avoid the 
test that f does not contain an occurrence of a defined function symbol, which is a sufficient 
condition to perform the assignment. 

Some of these problems can be tackled by nonstandard implementation architectures like 
memoization or bottom-up execution tfMarifio and Moreno-N avarro 1995t for the reevalu- 
ation problem, or parallel definitional trees (Antoy et al. 1997|lGenius 1996t to cope with 
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the lack of sequentiality but, in practice, these methods introduce their own overheads and 
actual implementations are based either on extensions of abstract machines for the execu- 
tion of functional languages or logic languages, or on the translation to another declara- 
tive language, like Prolog, see ("M arino and Moreno-Navarro 1992l|Marino and Rey 1998| l. 
This is why we chose to attack the problem at compile time or, in other words, how our 
research on demand analysis began. 



1.2 Paper Organization 

Section 121 introduces the subset of the Curry language we are going to use along the pa- 
per as well as the operational semantics used, namely narrowing. Section|3lintroduces the 
formalism of partial predicates, their structure and how demand properties can be repre- 
sented by using them. Section |3 discusses the problem of checking and inferring demand 
properties of a program. Different sublattices of demand properties, with increasing com- 
plexity, are introduced. Checking is demonstrated in an abstract way, by means of syntactic 
transformations (fold/unfold). Later, the harder problem of inferring demand properties is 
considered, firstly ('Section l4!2l . in an abstract way and then (Section|5} in connection with 
a particular analysis tool. Correctness of the aforementioned demand equations is shown 
there as well as the algorithms to compute approximate solutions to them. Code generation 
based on the information from the analyzer is discussed in Section |6l and a few experi- 
mental results showing the feasibility of the method are shown in Section|6l Some related 
work is discussed in Section0and open issues in Section|S] Finally, Section|5]concludes. 
In order to make this paper as self-contained as possible, [Appendix A| includes the ref- 
erence denotational semantics for the kernel language. [Appendix B| contains some proofs 
that have been removed from the printed version due to lack of space. 



2 Preliminaries 

This section is devoted to fix the subset of Curry that will be used along the paper The 
operational semantics assumed is discussed too. 



2.1 Kernel Language 

The language of choice is largely immaterial but a little syntax is needed in order to keep 
some coherency throughout the paper. We will use a simplified version of the functional- 
logic language Curry (IHanus et al. 20031 . basically a language of recursion equations, with 
a Haskell-like syntax. In the sequel we assume some knowledge of functional-logic lan- 
guages and Curry operational semantics. 

We assume a ranked set TC - IJ,, TC" of type constructors K and a countably infinite 
set TV of type variables a. Any data type is uniquely denoted by an algebraic term t e 
T(TC U TV) or a function type (ti —> T2). Next, we assume a set DC = \J„ DC" of typed 
data constructors C, a countably infinite set VS of variable symbols x, and a set FS of 
function symbols f with declared principal type f : ti r„ ^ t where t is not a 

function type. TC, DC, VS and FS are disjoint. The arity of a data constructor C e DC" 
is n and is denoted ar(C). In practice, type and data constructors are both defined via data 
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declarations of the form 

data K ai . . .ai - Ci Til ■■• Tim, \ ■ ■ ■ \ €„ t,,! . ■ . T „„,„ . 

A type constructor Bool with data constructors True and False is always assumed. Expres- 
sions are given by the grammar 

e ::= C I I / I ei 62 . 
Expressions must be well typed. A program is a set of defining rules of the form 

/ei ...e„ = -^]e. 

The optional condition b of type Bool is called the guard of the rule. Several restrictions 
are imposed on the rules in a program in order to ensure confluence of reduction, and the 
following are used somewhere in the paper: (i) for every rule (/ - r), I is a pattern, i.e. it 
has a single function symbol at its top and no variable occurs twice in I; (ii) rules must be 
well typed; (iii) for every pair of program rules {li - ri ), {I2 - r2), if li and I2 have a unifier 
cr then cr(ri) = cr(r2); (iv) free variables - i.e. those occurring in the right hand side but 
not in the left hand side - are allowed only if their rightmost occurrence is in the guard. 
Moreover, they must be of first order type. Observe that we are not forbidding overlaps. 
The set of rules defining function symbol / in program P is denoted Rulesp(f). 

When looking at the syntactic shape of the left hand sides of defining rules, a total 
application if ei ... e„) is treated as the algebraic term /(ei, . . . , e„) and then the standard 
notation for positions and substitutions is used. A position is a string of natural numbers 
that identifies a path to a subterm in a term. The expression t\p denotes the subterm of f at 
position p, i.e. /(ei, . . . , e„)|,.p - ei\p and f|f = f, with e the empty string. Replacement of 
t\p by f' is abbreviated t[t']p. The topmost symbol of term t is denoted root{t). 

A denotational semantics for the kernel language can be found in |Appendix A| Although 
not strictly necessary to understand the techniques proposed here, this is the ultimate foun- 
dation for the validity of the equations and inequalities used and supports the validity of 
the fold/unfold transformations. 

2.2 Narrowing 

The fundamental computation mechanism of functional-logic languages is narrowing. In- 
formally, to narrow an expression e means to apply a substitution that makes it reducible, 
and then reduce it. An expression e narrows to e' with substitution cr, if ;5 is a nonvariable 
position of e, Z = r is a variant of a program rule sharing no variables with e, and cr is a 
substitution such that <t(1) - o-{e\p), and e' = o-(e[r]p). 

As we have mentioned, unrestricted application of the narrowing rule is too nondeter- 
ministic and many strategies have been proposed to improve this. From an expressiveness 
point of view, we prefer those with a lazy behaviour because functions can be defined more 
independently, without interaction among them, thus increasing modularity and reusabiUty 
and allowing programming techniques like infinite objects. A general description of lazy 
narrowing for functional-logic languages can be found in ( JMoreno-Navarro and Rodriguez- Artalejo 1992) . 

The task of a narrowing strategy is the computation of the step, or steps, that must be 
applied to a term. A narrowing strategy suitable for functional-logic languages must be 
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sound, complete, and efficient. The intuition behind the soundness and the completeness of 
a strategy when the initial term of a derivation is an equation containing unknown variables 
is easy to describe: Soundness guarantees that any instantiation of the variables computed 
by the strategy is a solution of the equation. Completeness ensures that for any solution of 
the equation, the strategy computes another solution which is at least as general. 

However, efficiency is more difficult to state. As usual, the goal is to minimize the over- 
all time and memory consumed when finding one or all the values of an expression. In 
the narrowing context, it is related with the length of the derivations, and, specially, with 
the size of the search space. Basically, the two factors affecting the efficiency of a strategy 
are: (i) unnecessary steps should be avoided, and (ii) steps should be computed without 
consuming unnecessary resources. Lazy narrowing steps try to be applied at outermost po- 
sitions but to preserve completeness (see ( |Moreno-Navarro and Rodriguez- Artalejo 1992) ) 
inner arguments of a function are evaluated, by narrowing them to their head normal forms, 
if their values are required for an outermost narrowing step. 

In general, a strategy cannot easily determine if a computation is unnecessary without 
look-ahead. 

The strategy used in Curry is needed narrowing ( |Antoy et al. 2000| l, a lazy strategy 
where the program is translated into a set of definitional trees, one for every function sym- 
bol being defined. Definitional trees are given by the grammar 

DT ::= branch {Pattern, Pos [, DT ]+) | rule Rule \ or (DT[, DT]^) , 

where Pattern stands for patterns made up of data constructors and different variables as in 
the left hand sides of program rules, Pos are positions defined in the standard way and Rules 
are program rules. Trees without or nodes are called (inductively) sequential, otherwise 
they are parallel definitional trees. 

Given an expression e and a set of definitional trees for the defined symbols of the 
program, a position in e can be chosen to apply narrowing. This is done by first looking 
for an outermost application fe\ . . .e„ where / is a defined function symbol, and then 
descending some e, according to /'s definitional tree. Therefore, needed narrowing with 
sequential definitional trees establishes an efficient algorithm for implementing the look- 
ahead for required evaluations. In ( ^Antoy et al. 2000^ the formal definition is given but 
also an interesting property is shown: the strategy is optimal with respect to the length of 
derivations. 

To overcome the restriction to inductively sequential programs, other strategies have 
been proposed. For instance, the strategy of ( |Loogen et al. 1987j is based on some form of 
generalized definitional trees. The completeness of this strategy is unknown. These strate- 
gies are demand driven, which informally means the following: a subterm v of a term f is 
evaluated if there is a rule R potentially applicable to f that demands the evaluation of v. 

The lack of well-defined strategies with provable properties motivated alternative efforts 
for computations in this class. In our case, we use the information provided by demand 
analysis to guide the computation. The analysis, its formal properties and the use of demand 
information for implementing efficiently functional-logic languages are the goal of the 
following sections. 
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3 Partial Predicates 

This section is devoted to introduce the formahsm of partial predicates. Informally speak- 
ing, they are logic predicates that represent the degree of evaluation of an expression (de- 
mand properties). The main feature is that they can be described using the language under 
analysis, so the language itself is used to abstract some properties of a given program. This 
fact is essential for their use as an analysis tool, as will be shown later.^ 

Definition 1 (Partial Predicate) Let Two be a two point domain; a partial predicate n 
defined on type t is any continuous map n e t ^ Two which can be defined in the 
kernel language. In the following, the type scheme PP a will be used as synonymous with 
a — > Two. 

A two point domain Two is isomorphic to the subset of the domain Bool - {True, False, ±) 
after removing False^ and can be defined in the kernel language: 

data Two = True 

The definition of conjunction and disjunction functions in Bool can be restricted to this 
domain: 

(&&) , (II) : : Two -> Two -> Two 
True && True = True 

True I I y = True; x | | True = True 

Observe that disjunction in Two is given by a parallel definition. While this could be prob- 
lematic in case of trying to execute the program, it is not the case in our context as long as 
the definitions of the predicate transformers will mainly be used for program transforma- 
tion. 

Every partial predicate n of type PP r represents subsets of the domain t: 

n^^{True) = {x € t | 7t(x) = True} . 

Example 2 (Peano naturals) Some of the examples throughout the paper will make use 
of a data type for Peano naturals: 

data Nat = Zero | Succ Nat 

A pair of predicates hnfNat and nfNat can be introduced: 
hnf Nat , nfNat : : PP Nat 

hnfNat Zero = True; hnfNat (Succ _) = True 

nfNat Zero = True; nfNat (Succ n) = nfNat n 

The former yields True when its argument is evaluated enough to identify its topmost 
constructor The latter yields True when its argument is evaluated to normal form. Observe 
that hnfNat n - ± ■i^ n - ±. 

^ From this point on, notation based on domain theory is extensively used, and a denotational semantic s fo r 
the kernel language is assumed. Readers less familiar with these topics are referred to (.van Leeuwen 19901 . 
Chapters 1 1 and 12. 

^ Hence the name of partial predicates. 
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Example 3 (Partial predicates hnfList and spine) Less trivial are those predicates that 
can be used to express properties of polymorphic types. Consider, for instance, hnfList 
or spine in the domain of polymorphic lists: 

hnfList, spine :: PP [a] 

hnfList [] = True; hnfList (h:ts) = True 

spine [] = True; spine (h:ts) = spine ts 

Analogously to the example above, the former yields True when its list argument is evalu- 
ated enough to identify its topmost constructor The latter yields True when the argument 
is evaluated enough to reach the end of the list. In both cases, the degree of definition of 
the elements in the list is immaterial. Observe again that hnfList xs - ± <^ xs - ±. 

Example 4 (Partial predicates any and nothing) A pair of polymorphic partial predicates 
any and nothing can be defined for all types: 

any , nothing : : PP a 

any x = True ; nothing x - nothing x 



3.1 Demand Typings 

Partial predicates can be used to express a great number of program properties, including 
classic strictness. For instance, suppose we are interested in proving f e [ti] — > Nat 
strict:'* 

/ is strict o /± = ± o Vx. x = ±=>/ji: = ± 

» Vx. hnfNat(f x) — True => hnfList x — True 

o Vx. hnfNatif x) C hnfList x o hnfNat o / C hnfList 

So the property '/ is strict' is equivalent to hnfNat o / c hnfList. 

If we are interested in studying how much information is needed in a function's argument 
in order to obtain a certain amount in the result, this can be generalized to properties of the 
form o / c . 

Definition 5 (Demand Properties, Demand Types and Demand Typings) A demand prop- 
erty is an inequality of the form 712 o / C tti where tti and 1x2 are partial predicates defined 
on the domain and codomain types of /, respectively. It is denoted in the following way: 

J. def J. 

/ : TTl <^ 712 = 7r2 ° / C TTl . 

n\ 7r2 is a demand type and / : tti ;r2 is a demand typing. 

Demand typings f '. n\ <^ are usually read '/ demands n\ to its argument in order 
to give a result as evaluated as n^' Our previous strictness example would be rewritten 
/ : hnfList hnfNat . It is rather simple to show that for any partial predicate n^\True) 
is an ideal - it is the inverse image of a closed set. In fact, 'partial predicate' can be taken 

A formal definition of strict can be found in Definition ll6l 
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as synonymous with 'computable ideal.' The lattice of partial predicates induces another 
on demand types ni 712'- covaiiantly on m and contravariantly on 712- 

3.2 Polymorphism 

One advantage of partial predicates over other approaches to program analysis, such as 
abstract interpretation on finite domains, is a natural treatment of polymorphism. Being 
written in source code they have the same type constraints and expressiveness. 

Some partial predicates presented so far are polymorphic and the same can be said of 
the predicate transformers to be introduced below. 

Definition 6 (Predicate Transformers) Predicate transformers are higher order functions 
that take partial predicates as (part of) its argument and yield partial predicates as result. 

Data constructors can be seen as predicate transformers, in particular, polymorphic con- 
structors can be represented by polymorphic transformers. 

Definition 7 (Constructor Predicate Transformer) Consider a type definition of the form 

data K ai . . . ai - . . . | C; T] . . . t„,, | . . . 

The constructor predicate transformer c,-^ associated with each data constructor is defined 
as follows: 

a : : PP Ti ...^ PP T„,, PP CK ai ... aO 

Ci Pi ... Pm, CC,- xi ... x,„_) = (pi xi) && ... && (p„,, x,„_) . 

Interesting partial predicates associated to data constructors and data types can be de- 
fined by using constructor predicate transformers (e.g. Definition|S]and DefinitionllOk 

Definition 8 (Matcliing Predicates) For every data constructor C the partial predicate isC 
defined 

isC :: PP CK ai ... a/) 
isC = (c any . . . any) 

is called the matching predicate for constructor C. 

Definition 9 (Meets and Joins) The greatest lower bound operator n (/\) and the least 
upper bound operator U (\/) can be defined: 

(A) , (\/) : : PP a -> PP a -> PP a 

(p /\ q) X = (p x) && (q x) ; (p \/ q) x = (p x) | | (q x) 

Definition 10 (hnf Predicates) For every type constructor K with data constructors Ci , 
. . . , C„, the partial predicate hnfK defined 



^ We are not actualy overloading data constructor names but just changing first letter of the name to lowercase. 
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hnfK :: PP CK ai ... a,) 
hnfK = isCi U . . . U isC„ 

is the hnf predicate of K. 

Example 11 Constructor predicate transformers and matching predicates associated with 
the Hst constructors [] :: [a] and (:) : : a — > [a] — > [o']* are: 

nil : : PP a isNil : : PP [a] 

nil [] = True isNil = nil 

cons : : PP a -> PP [a] -> PP [a] isCons : : PP [a] 

cons p q (x : xs) = (p x) && (q xs) isCons = cons any any 

The definition of hnfList in Example|3lcan be rewriten 

hnfList : : PP [a] hnfList = isNil \/ isCons 

Example 12 The constructor predicate transformer and the matching predicate associated 
with the tuple constructor (, ) :: a — > /? ^ (a,/?)^ are: 

tup2 :: PP a -> PP b -> PP (a,b) isTup2 :: PP (a,b) 

tup2 p q (x,y) = (p x) && (q y) isTup2 = tup2 any any 

And the definition of hnfTup2 is: 

hnfTup2 :: PP (a,b) hnfTup2 = isTup2 

Definition 13 (Cartesian Products) The cartesian product of two partial predicates is de- 
fined as the constructor predicate transformer tup2. In the following we will use the infix 
operator (x) :: a ^ /3 ^ (ff,/?) as synonymous with tup2. The definition is gener- 
alised to arbitrary length tuples: 

(Pi X ... X p„) (xi, x„) = (pi xi) && ... && (p„ x„) 

Example 14 (Projections on Tliples) A cartesian product implies the existence of projec- 
tions. We will show that there are actually two predicate transformers prjl and prj2 with 
types 

prjl :: PP (a,b) -> PP a prj2 :: PP (a,b) -> PP b 

although their definition is somewhat special. Mathematically, the following must hold: 

(prjl pY^ = [x I 3y. p{x,y) = True] 
(prjlpY^ = [y \3x. p{x,y) ^ True] . 

As has been said in the introduction, the kernel language does not forbid free variables 
in the equations. In fact, the denotational semantics of rules treats them via a least upper 
bound quantified over all the possible values in their type. This means that an implementa- 
tion of projections will be: 

* We are using List, Nil and Cons as names for ([]), [] and (:), respectively. 
' We are using Tup2 as the name for ( , ) . 
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prjl p X = p (x, y) -> True; prj2 p y = p (x, y) -> True 

This can be surprising to the reader more biased towards functional programming but is by 
no means strange if we look at Prolog or functional-logic languages as Curry itself. In the 
special case that the variable being quantified is of a first order type, implementing such an 
equation is not a problem. 

The extension of projections to arbitrary data types and data constructors is trivial. In 
particular projections on arbitrary length tuples will be used in the following section. 

Definition 15 (Projections) Given the data declaration scheme 

data K a\ . . . ai — . . . | C; ti . . . t„,^ | . . . 

for each data constructor C, and for each k e {!,..., m,), the projection partial predicate 
prjkCi is defined as^ 

prjkCi :: PP Tk ^ PP iK ai ... a/) 

prjkCi p X = p (C; xi ... X ... x,„,) True . 



4 Cliecking and Inference of Demand Properties 

This section studies some analyses and their domains of properties under the prism of 
partial predicates. The novelty of our approach is that, by expressing partial predicates in a 
subset of the programming language under analysis, a program transformation approach is 
feasible. All the examples below use the well known fold/unfold transformations and are, 
thus, trivially correct for a language with a lazy declarative semantics. 



4.1 Checking 

The problem of deciding if a given partial predicate fulfills the demand information of a 
given function is the checking problem: to prove that given /, tti and 712, f '■ 7t\ ^2 holds. 

Concrete analyses fix a specific domain of checking properties, i.e. only a limited num- 
ber of partial predicates are allowed. Let us show the translation of several domains of 
properties into the language of partial predicates and exemplify checking by means of 
equational reasoning. 

Classic Strictness Analysis. The first attempt to mechanize strictness analysis is found in 
l |My croft 1 980*). The aim is to detect when an argument can be safely reduced in advance 
without affecting the termination properties of the program. 

Definition 16 A function / is said to be strict iff / ± = ±. 

Due to evident practical reasons, this definition is relaxed to cope with the usual case of 
the argument belonging to a product type: 

* Observe that k actualy expands: prjlCi, pr/2C,, . . . 
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Definition 17 A function / is said to be strict in its i-th argument iff 

V JCl . . . JC;_1 Xi+l ...X„. f(Xl,. . . , ±, . ..,x„)^±. 

As we have seen in Section ITTI the first case can be expressed in our setting by saying 
that the function demands an argument strictly more evaluated than ± in order to pro- 
duce a result strictly more evaluated than ±. When both the argument and result types are 
constructed, values other than ± can be finitely presented by enumeration of the different 
constructors in the type: 

Lemma 18 If / is a function with type f :: Kt K't' then it is strict iff" / : hnfK 
hnfK' . 

Proof 

See proof in Section lsTl and replace Nat and List with K' and K. □ 

Let us see an example that will also show how to use equational reasoning in order to 
prove the demand typing correct. 

Example 19 Function length 
length : : [a] -> Nat 

length [] = Zero; length (h:ts) = Succ (length ts) 

is strict. This will be expressed as length : hnfList <^ hnfNat. Using the definitions of 
hnfNat and hnfList seen before, we have to prove that hnfNat o length c hnfList. Then 
these equivalences follow from the semantics of the kernel language:^ 

(hnfNat . length ) [] = hnfNat (length []) = hnfNat Zero = True 
(hnfNat . length ) (x:xs) = hnfNat (length (x:xs)) 

= hnfNat (Succ (length xs)) = True 

Both rules coincide with the equations of hnfList. 

Lemma 20 If / is a function with type / : : (/TiTi , . . . , K„t„') — > Kt' then it is strict in 
the i-th argument iff / : any x . . . x hnfKi x . . . x any hnfK . 

Proof 





hnfK 


o / C any X 


... X hnfKi X ... X 


any 






Vxi . 


. . jc„. hnfK(f(xi , . . . , x„)) c (any X . 


. X hnfK 


X ... X any){x\ 




Vxi . 


. .x„. hnfK(f(xi , . . . , x„)) c hnfKi{xi) 








V jci . 


■ . Xi-l Xj-i-l . . 


x„. hnfK(f(xu. . .,Xi-u 


±,X,+ 1,..., 


x„)) C hnfKiil.) 




V jci . 


■ . Xi-l Xl-i-\ . . 


x„. hnfK(f(xi , . . . , , 


±, Xl+l, . . . , 


Xn)) C J- 




Vxi . 


■ . Xi-l . . 


x„. hnfK(f(xi , . . . , , 


±, . . . , 


Xn)) = -L 




Vxi . 


■ ■ Xi-l . . 


Xn- f(x\, . . . , ±, 


, . . . , x„)) = 


X . 


□ 













' Composition in Curry is denoted by witli tlie symbol ' . ' . 
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Example 21 Function plus 



plus :: (Nat, Nat) -> Nat 
plus (Zero, m) = m; 



plus (Succ n, m) = Succ (plus (n, m)) 



is strict in its first argument: plus : hnfNat x any hnfNat . Unfolding the definition of 
hnfNat X any we get 

(hnfNat X any) (x,y) = (hnfWat x) && (any y) = hnfNat x 
Unfolding hnfNat o plus: 

(hnfNat . plus) (Zero,m) = hnfNat m C hnfNat Zero 
(hnfNat . plus) (Succ n,m) = True = hnfNat (Succ n) 

so hnfNat o plus C hnfNat x any and, by Definitionlsj plus : hnfNat x any <= hnfNat . 

Wadler's Four Point Domain. Many interesting properties are related to the degree of eval- 
uation required on recursive data structures, like lists. For instance, function length needs 
a nil-ending list in order to produce a definite result, but it is immaterial whether one or 
more of its elements is undefined. 

In JWadler 1987> a four point abstract domain of degrees of definiteness of monomor- 
phic lists is introduced. The domain, in increasing order, can be given as; 



representing, respectively, the undefined list, any list with an undefined suffix, finite lists 
with some undefined elements and total lists. The original paper is not very formal and 
does not make clear that this semantics for the four elements does not provide conjunctive 
nor disjunctive closeness. This, of course, can be achieved if their semantics is changed 
into: 



oo any list in head normal form ± an undefined list . 

These four levels of definiteness can be represented in our framework by the three partial 
predicates: hnfList, spine, and nfListNat: 

nfListNat : : PP [Nat] 

nfListNat (xixs) = (nfUat x) && (nfListNat xs) ; nfListNat [] = True; 

The following can help demonstrate the transformational approach. Let us prove length : 
spine nfNat. Let R denote nfNat o length. Applying standard fusion techniques (see 
Section l4~2t we successively obtain: 

R [] = nfNat (length []) = nfUat Zero = True 

R (x:xs) = nfNat (length x:xs) = nfNat (Succ (length xs)) 



4 = 



{± C oo C ±6 □ T€ ) 



Te any list 



±e any nil ending list 



= nfNat (length xs) = R xs 



so we conclude that R - spine. 
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Fig. 3. The lattice of uniform properties on lists. 



Uniform Properties. A number of proposals have been made to generalise Wadler's four 
point domain to any algebraic datatype. Intuitively, the uniform properties of a data struc- 
ture are those invariant under any (type preserving) permutation of the elements of the 
structure. For instance, if p is an uniform property of lists of naturals, then piZero : 
{SuccZero) : ±) o p((Succ Zero) ; Zero : ±). 

In (Uensen 1994^ a powerdomain construction for uniform properties over algebraic 
datatypes is given, using modalities, along with a strictness logic for reasoning about 
those properties. His domains are able to express certain properties that do not appear 
in Wadler's, like a list being empty or being finite with all their elements undefined, etc. 
The formalism is rather involved and the strictness logic does not lead very naturally to an 
implementation. 

Trying to accommodate those ideas into our framework of partial predicates we imme- 
diately see that the domains that arise in Jensen's work correspond essentially to the folds 
on a given datatype. A fold on a data structure is a transformation that replaces every n-ary 
constructor by an n-ary function. Folds are generic programming constructs in the sense 
that folds can be defined for every algebraic datatype in an uniform way. For instance, 
folding lists is done using the following higher order operator: 



foldl : : (a -> b -> b) -> b -> [a] -> b 

foldl f b [] = b; foldl f b (x:xs) = f x (foldl f b xs) 

Due to type restrictions, the number of partial predicates on natural lists that can be defined 
as folds is limited. If only two degrees of definiteness are considered for the naturals (± 
and True) that leaves six possible combining functions of type Two —> Two — > Two : 

(co) Ax. Ay. ± (ci) Ax. Ay. x (ci) Ax. Ay. x Ay 
(C3) Ax. Ay. True (C4) Ax. Ay. y (cs) Ax. Ay. xV y 
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times two values for the base case gives a lattice (Figure |3} of at most 13 abstract values 
(adding any).'*' A similar domain appears in (Bento n 19 92). 

The possibility of using catamorphisms (fold-like functions) on algebraic types as a way 
of automatically constructing domains for the analysis of programs has been studied and 
implemented in ( |Rey 2003) . 

4.2 Inference 

Here we study the problem dual to checking, i.e. how to infer a partial predicate that de- 
scribes (with reasonable accuracy) demand information for a given function. The concrete 
inference problem considered in this paper is the following: given / and 712, to find the 
best n\ such that f : n\ <^ ni holds and, more important, to give a usable representation. 
The best n\ such that f : n\ <= 7r2 is tti - ni o f and an explicit (recursive) definition 
can be obtained using the transformational approach used for checking. However, giving a 
compact representation of n\ suitable for code generation can be difficult and here is where 
a purely symbolic approach is better suited than the program transformation one. 

In order to get an informal understanding of the connection between the program trans- 
formation and the symbolic approaches to inference, let us revisit Example^]recast as an 
inference problem: 

Example 22 The original program is 

length [] = Zero; length (h:ts) = Succ (length ts) 

We want to infer the degree of definiteness demanded n\ on its argument by a result in 
normal form, i.e. n\ - nfNat o length, so the following must hold: 

^1 ([]) = (nfNat o length) ([]) 

— nfNat (Zero) — True 
n\ (h : ts) — (nfNat o length) (h : ts) 

— (nfNat o Succ) (length (ts)) . 

It is easy to see that nfNat o Succ simplifies to nfNat so 

TT] (h : ts) — nfNat (length (ts)) 

— (nfNat o length) (ts) — ni (ts) , 

resulting in a rather generative set of equations for n\ (that coincide with equations for 
spine). 

The following section shows a more systematic method to manipulate partial predicates 
properties in a fully symbolic way. From the program under analysis and the inference 
question, a set of inequalities among symbolic representations of partial predicates is gen- 
erated, and is this set which is manipulated - although the meaning of these rewritings 
must mimic the original program transformations. 

The notation (c, v) stands for foldl c v . The exact cardinality of the abstract domain is 1 1 , as some of the 
combinations coincide: /oWZ C2 X = foldl C4 ± = foldl Co -L ■ 
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5 From Partial Predicates to Set Expressions 

The most natural interpretation of a partial predicate tt e o' — > Two is a subset of the domain 
Da, a set of trees, more exactly an ideal set of partial trees. This section is devoted to show 
that set expressions and set constraint based analysis ( Pachols ki and Podelski 1997t can be 
used as a framework for the checking and inference of partial predicate typings. 

5.7 Basic Notions 

'Set constraints are first-order logic formulae interpreted over the domain of sets of trees' 
(^Pachols ki and Podelski 19971 . Set expressions (e) are expressions built from variables in- 
terpreted over sets of trees, function symbols intepreted as functions over sets of trees and 
standard set operators (union, intersection, inclusion, complement, etc.). A system of set 
constraints is a conjunction of inclusions of the form e; c with some restrictions on the 
set expressions that can appear in the left or right hand sides. 

Co-definite set constraints (ICharatonik and Podelski 1998t is the class of set constraints 
where constraints are inclusions between positive set expressions and where the set ex- 
pression in the left hand side is restricted to contain variables, constants, unary function 
symbols and the union operator." Sets of co-definite constraints, if satisfiable, always have 
a greatest solution. The satisfiabilty problem for co-definite set constraints is DEXPTIME- 
complete and an algorithm is given in JCharatonik and Podelski 1998> . 

The restriction to positive expressions - i.e. without the use of complementation - is es- 
sential for our purposes, as the complement of an ideal is not an ideal. The rest of operators 
are continuous, so we can translate existing results in set constraint theory to our domains. 

The following definitions formalize these notions. 

Definition 23 (Set Expressions) Given a typed alphabet 2 with constants (a, b,c, . . .) and 
nonconstant function symbols (/, g,h, . . .) and a typed set VS of variable symbols (m, v, 
x,y, . . .), set expressions follow the syntax:'^ 

e ::= x | a | /(mi, . . . , m„) | /(^'(m) | ei U I • 

This syntax represents finite and infinite trees and we will use the notation for the whole 
set of well-formed (w.r.t. types) trees. 

Definition 24 (Valuation) A valuation {cr) is a function from variable symbols to proper 
subsets of Ty. (cr : VS ^ 2^^). 

Definition 25 (Interpretation of Set Expressions) Given a valuation cr, the standard in- 



In Defimtion l28l a restricted but equivalent characterisation is proposed. 
The symbol originally used in set constraint theory is ±. 
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terpretation la- of set expressions over E and VS is defined as'^ 

/o-(x) - crix) 
lo-(a) - {a] 

IAf{ui,...,u„)) = {/(f;,...,f„) I V/e {!,...,«). f, e/^(M,)) 

W(k] («)) = {f I 3f I , . . . , f„. = f A /(fl , . . . , f„) e /tr(M)} 

/^(e, U ez) = /^(ei) U Uez) 

Definition 26 (Solution) A valuation cr is a solution of a set constraint e/ c e,- iff 

/^(e/) C I^ie,) . 

Definition 27 (Satisfaction) A system of set constraints S is satisfiable if there is some 
valuation cr that is a solution of every constraint in S . 

Definition 28 (Co-definite Set Constraints) A constraint (pi& a co-definite set constraint 
when it follows the syntax: 

T ::= X I /(mi, . . . , M„) I Ti U T2 I 
(fi ::= aQx\xQT\xQ fij;)(u) ■ 

We will use the notation {(pi,(p2, . . . , (p,,} to refer to the system tpi A (p2 A ■ ■ ■ A (p„. 

5.2 Co-definite Set Constraints and Partial Predicates 

A partial predicate n is interpreted as the set ji^^ijrue) - [x e T^. \ 7i{x) - True] that is 
in the codomain of interpretations of set expressions. Conversely, if S is an ideal, 11(5) 
will denote its corresponding partial predicate, i.e. 11(5 )(x) - True if x e S , otherwise 
Yi{S){x) - ±. We will encode partial predicates as variables and the greatest solution of a 
system of co-definite set constraints. 



Example 29 (Some basic partial predicates) The following table shows how some par- 
tial predicates can be encoded (z, s, n and c refer, respectively, to constructor predicate 
transformers zero, succ, nil and cons as described in Definition^}: 



Partial predicate 


System of set constraints 


Variable 


hnfNat - z U s(any) 


{hnf Q X D y, X C Zero,y C Succ(-)] 


hnf 


nfNat - z Li s(nfNat) 


{nf Q xDy,x Q Zero,y C Succ{nf)} 


nf 


nfListNat - n Li cinfNat, nfListNat) 


{«/ c M u V, M c [], V c (nf : nf). 


nf 




nf Q xD y,x Q Zero,y C Succ{nf)} 




spine — n Li c(any, spine) 


{snf c M u V, M c [], V c (_ : snf)} 


snf 



where _ represents fresh variables. 



Where symbols U and are overloaded. 
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Example 30 (Dependency) The intrinsic difficulty of working with dependency that was 
akeady patent in (Marinoet al. 1993) can be put in relation with the syntax of set con- 
straints. A typical property that can be represented with dependent demand patterns is that 
a pair is made of lists of the same length. For instance, a demand typing for function zip 

zip :: ([a],[b]) -> [Ca,b)] 

zip ([],[]) = [] ; zip (x:xs,y:ys) = (x,y) : (zip (xs,ys)) 

is zip '■ spine samelength where 
samelength :: PP ([a],[b]) 

samelength ([],[]) = True; samelength (x:xs,y:ys) = samelength (xs,ys) 

The greatest solution to the following set constraint system for the variable si captures the 
dependent information of the partial predicate samelength: 

{si c (/i, /2) U (l\,l'2), h £ [], h £ [], l\Qx: xs, l^Qy: ys, {xs,ys) c si} . 

But this system is not co-definite (last constraint has a binary function symbol in the left 
hand side). In order to get a co-definite set constraint system, the last constraint is substi- 
tuted by two constraints: xs c (, )j^j'(sO and ys c (, )p'(sO- With the substitution we have 
lost the dependency information. Nevertheless, the solution is correct with respect to the 
interpretation of the partial predicate in the following formal sense: 

samelength^^ {True) C Ia-{sl) 

where cr is the greatest solution to the system of co-definite set constraints. 

5.3 Generating Co-definite Set Constraints 

DAC (Demandedness Analysis for Curry) is a tool that generates a system of co-definite 
set constraints from a given program. In this section we explain how DAC generates the 
system. Observe that the solving of a system of set constraints is completely independent of 
the application, i.e. the fact that we are encoding partial predicates is immaterial. Observe, 
as well, there could be other ways to generate correct systems of constraints. 

In the first place, we need to introduce the logic that relates the variables in the system 
of set constraints with the meaning of the program. This connection relies on the fact the 
partial predicates the user is interested in are defined as functions in the kernel language. 

Definition 31 (Variable Construction) Given f e FS and p e FS, with types ti — » t2 
and PP T2, respectively, the infix operator (•) is used to construct a new variable p»f e VS 
that represents the degree of evaluation demanded by / in order to give a result as evaluated 
as p. 

Auxiliary variables are introduced for different subterms in the program equations that 
define /: 

- p»f.i refers to the demandedness information introduced by the i-th equation defining / 

- pff.i.pos refers to the subterm lhs\pos if Ihs is the left hand side of the ;-th equation defin- 
ing /■ 



Demand Analysis with Partial Predicates 



21 



nf^lus Q nftplus.l U nf^lus.2 

nf^lus.l c (nf«p/;(.s.l.l, nf«pZMi.l.2) 

nf^lus.l.l c Zero 

nf^lus.1.2 c nf 

nf^lus.2 c (5;(fc(nf^:)/j«2.1.1),nf«pZM.s.2.2) 



(1) 
(2) 
(3) 
(4) 
(5) 
(6) 
(7) 
(8) 
(9) 



SMCc(nf_p/i«.2.1) c nf 



nf^Zwi-.2.1.1 c nf^lus.lAA.l 
nf»plus. 2.2 c nf_p/Mi.2. 1.1.2 



(nf_pZ;«.2.1.1.1,nf47/w.s.2.1.1.2)) c nftplus 



Fig. 4. Set of constraints generated from program plus 

- p_f.i.pos refers to the subterm rhs\pos if rhs is the right hand side of the /-th equation 
defining /. 

Finally, the constraint generation algorithm generates variables of the form (q*g)»f- Al- 
though these can be given a neat interpretation, the constraint solver will treat them as 
indivisible, so they will have to be transformed in some way in order to be useful. 

The intuitive meaning of d»f is to denote (an approximation of) c/ o / . This connection 
will be formalized below. The intuitive meaning of p'f.i.pos is the projection at position 
pos of the set p»f.i . Variables generated from positions in the right hand sides have a less 
evident meaning or, perhaps, more operational but they provide valuable information for 
compilation. 

Example 32 Figure|3]shows a system of constraints generated from function plus (Exam- 
plel21> to give a result in normal form. 



The generation scheme is presented here as a set of rules. These will be stated in a mod- 
erately informal way, in order to hide some of the details to the reader, especially those 
concerned with the handling of occurrence indices. 

Rule 1 (Main Function Constraint) Given a partial predicate symbol p and function sym- 
bol /, with defining rules 

fti^bi ... f t„= b„ 
the following constraint is generated: 

p»f C p.f.l U ... U p./.n. 



5.4 Generating Systems of Set Constraints 



Hence the choice of the symbol '•' 
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Rule 2 (Main Rule Constraint) For every rule 

fiitu...,tn) = bi 

the following constraint is added: 

p»f.i c ip»f.i.l, . . .,p»f.i.n) . 

Notice that this is a lossy step, i.e. possible dependencies among the arguments through the 
body of the rule (/?,) can be lost. This means that an analyzer based on program transfor- 
mation techniques can, at least theoretically, achieve a better accuracy. 

Rule 3 (Head Constraints) For every rule 

fiitu...,t„) = bi 

and for every J e { 1 , . . . , n} the following constraint is added: 

P'f.i.j c A(p,f,i.j,tj), 

where A is the function that constructs a set expression from a term by replacing every 
occurrence of a program variable with a demand variable decorated with its position, i.e.: 

A(p,f,i,c{ti,...,t„,)) = c(A(p,f,iA,ti),...,A(p,f,i-m,tm)) 
A(p,f,i,x) = ptf.i. 

This step usually generates superfluous constraints of the form v c v which can be dis- 
carded later. 

Rule 4 (Body Constraints) We can distinguish several cases here: 

1 . {The body is a variable) If the rule is of the form 

fi ih, ■ ■ ■ Jn) = X 

X being a program variable, the constraint 

p»f.iA.pos c p 

where pos is the position where x occurs in the left hand side, is added to the system. 

2. {The body is a constant) If the rule is of the form 

fi{tu...,tn) = k 

k being a constant, the constraint 

k Q p 

is added to the system. This constraint will often be trivial. 

3. {The body is a function application) This is the clumsiest case. To simplify the presentation, 
let us assume, without loss of generaUty, that the form of the rule is the following: 

fi{t) = g{h{i) h„{i)). 
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The constraints 

p.f.i.l c 

p_f.i.m c (, \^/fg) 
are added to the system, and also the constraints : 

p»f.i c /?_/./. Wii 

p»f.i c p_f.i.m4i,n . 
Notice that this step is responsible for the appearance of 'nested' demand variables. 

Rule 5 (Simplilication) In this step two kind of actions are performed: the shortcut of 
transitive chains and the simplification of nested demand variables. 

If a variable of the form (p*g)»f is found, and a concrete representation p' for (p*g) is 
known - which is usually the case when ^ is a data constructor - then it is replaced by /?'•/. 
This step is necessary when standard - i.e. problem independent - techniques for solving 
the constraint systems are going to be used. 

Rule 6 (Weakening) Sometimes it is not easy to compute the {p*g) of the previous step, 
so some sort of approximation is necessary, i.e. using any p" satisfying p" □ p' instead of 
p' . This is often possible. In the worst case any can be used. 

The following result states the soundness of the analysis based on the solution of this set 
of constraints. 

Theorem 33 (Soundness of the Analysis) Let S denote the system of constraints generated 
from a given program applying the rules above. Let o" be a solution of S . For every variable 
d»f occurring in S the following must hold: 

ni(r{d>m^dof. 

We will just sketch the proof here. A more detailed explanation can be found in |Appendix B| 
The idea is to apply a set of program transformation rules to J o /, for every possible com- 
bination of d and /, so that the resulting program is structurally similar to S . 

6 Application to Code Generation 

For the sake of brevity, we will not develop the issues related to code generation in full 
here. A detailed discussion can be found in (Marino 2002), first in an abstract fashion - 
by means of an operational semantics driven by degrees of definiteness - and then in the 
context of a stack-based machine. Anyway, code generation from the demand information 
(represented by partial predicates) is a challenging task on its own and some of the details 
of a full compiler are still open. 

The basic idea is that different, specialized versions of a given function can be compiled 
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example 


n 


eager 


naXve lazy 


demand driven 




10 


0.47 


1.00 


0.62 




11 


0.91 


1.98 


1.24 


sublists 


12 


1.86 


3.96 


2.42 




13 


3.68 


7.94 


4.80 




14 


7.42 


15.82 


9.60 




15 


15.05 


31.75 


19.23 




4 


1.06 


0.89 


0.21 


n queens 


5 


14.50 


10.55 


2.60 




6 


247.03 


174.30 


39.30 



Table 1. Runtimes of the example programs in seconds. 

for different degrees of evaluation demanded on its result. For instance, if the main goal of 
a certain program is 

?- mergeSort (f x) 

the result must be shown in normal form, so a special version mergeSort jif will be gen- 
erated. In order to give a result in normal form, the argument to mergeSort must also be a 
total value, which implies that / can also be replaced by an specialized version - f jif - 
and so on, i.e. demand is back-propagated from the result to the argument expressions. 

Some Experiments The following example programs were executed on a stack-based nar- 
rowing machine (Moreno-Navarro et al. 1990). The narrowing machine is an extension of 
a purely functional machine enriched by mechanisms for unification and backtracking, 
similar- to the WAM. 

Based on the implementation of the presented ideas on the stack-based narrowing ma- 
chine, we have tried some example programs and measured their runtimes with the naive 
lazy approach and with our new approach. Additionally, we have measured the runtimes 
for eager narrowing. 

We have investigated the following example programs: 1) the computation of all the 
sublists of reverse [!,...,«] , and 2) the «-queens problem (using a simple generate and 
test approach). Both examples have the property that a lot of reevaluations are needed 
since demanded arguments are not evaluated in advance. Due to space limitation we omit 
the code. The runtimes are depicted in Table[2 The examples show that the runtimes can be 
considerably improved, if the demanded arguments are evaluated in advance. Notice that 
in examples like n-queens, the lazy strategy is even better than the eager one. Moreover, 
bigger real examples have a lot of nested function calls, which implies a considerable risk 
of reevaluation. 

Table 121 shows the results obtained with the sublists o reverse example using the trans- 
lation into Prolog, with and without code optimization based on demand analysis. The 
measures have been taken in discrete resolution steps. 
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sublists o reverse [!,...,«] n 


without demand anal. 


with demand anal. 


ratio 


3 


41 


36 


1.13 


4 


88 


72 


1.22 


5 


183 


141 


1.29 


6 


374 


275 


1.36 


7 


757 


538 


1.40 


8 


1524 


1058 


1.44 


Table 2. Results in a lazy producer- 


■consumer scheme. 







7 Related Work 

Our original work on demand analysis JMarino and Moreno-Navarro 1992llMoreno-Navarro et al. 19931 

anno and Herranz?993llMarino et al. 1993> was based on the generation and solution of 
a set of demand equations that were solved in a domain of regular trees {demand patterns). 
Similar, in spirit, to the techniques presented in Section |5] a semantic justification was 
missing and the solving method was ad-hoc. Partial predicates provide the necessary se- 
mantic ground and the advances in set constraint resolution makes unnecessary to reinvent 
the wheel. 

With respect to partial predicates, the most striking similarity is with projection anal- 
ysis ( |Wadler and Hughes 1993^ . However, the rationale and meaning for these two for- 
malisms differ in some key aspects. A projection, in a domain-theoretic sense, is an idem- 
potent approximation to the identity (in a given type), i.e. a ;: r — » r is a projection (in t) 
iff a C id and a o a - a. 

While partial predicates try to be an extension of classic strictness analysis, projection 
analysis are designed to capture the property that a given function is invariant under cer- 
tain program transformations. The typical example is head-strictness, the property that a 
function on lists gives the same results when the list constructor in its argument is replaced 
by a version strict in its first argument. Mathematically, this transformation is a projection 
H :: [a] ^ [a], so the property of / being head-strict is expressed as / = / o H. In general, 
projection analysis studies properties of the form a o f - a o f o p, where a and fi are 
projections. These are abbreviated as f : a ^ /3. 

Properties expressible in both formalisms are different. First of all, let us show that head 
strictness cannot be represented by a partial predicate typing. 

Theorem 34 There is no pair of partial predicates 7Ti,jt2 such that the set of functions 
{/I/ : TT] <= 7:2] coincides with that of the head-strict ones. 

Proof 

Let us note that the property of being head-strict is just 'too polymorphic' as it does not 
take into account the type of the result, so equivalence just makes sense fixing a particular 
type, i.e. considering just the head-strict functions for a given type [cr] —> t. This makes 
the proof shorter, as we can restrict ourselves to the type [Bool] — > Bool. There will be 
just five possibilities for n2'- nothing, true, false, hnf and any. The key to the proof is in 
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considering the functions any, nothing (which are head-strict) and spine (which is not). 
Any combination of partial predicates which would hold for both any and nothing would 
also hold for spine, contradiction. □ 

Projections, on the other hand, are able to express partial predicate typings, but only 
if a tricky artifact is added to the formalism: assuming the existence in the domain of a 
new element (^ ) less defined than ±. This had to be introduced by Wadler and Hughes 
in order to capture classic strictness with projections, but complicates the formalism in 
several ways. The following result holds assuming programs are ^ -strict: 

Theorem 35 For every pair of partial predicates 7ri,;7r2 there is a pair of projections a,/3 
such that the set {f\f : ji\ <^ 712] coincides with {f\f : a ^ /3} — under reasonable type 
restrictions. 

Proof 

The proof is constructive. Define a and /3 in the following way: 

a X — X if 7:2 (f x) — true /3 x — x if tti x — true 

a X- i otherwise /3 x = ^ otherwise . 

Let us examine both implications: 

(i) (/ : TTi <= ;r2 ^ f : a ^ /3) 

There are two possibilities for any argument x to /: 

a) (x e TTi) Trivial: (a o f o j3) x - (a o f)(J3 x) = (a o f) x. 

b) {x i ni) In this case we know that f x in2- So, in one hand we have: 

{aofol5)x^a{f{]3x))^a{fi)^ai = i . 
On the other hand, using the fact that f x i 112, a( f x) - 

(ii) {f-.a^p ^ / : TTi <^ TTz) 

Using reductio ad absurdum: suppose there is some z s.t. z i n\ and / z e 712. Then it is 
trivial to show that (a o f op) z = i and {a o f) z- f z, contradiction. □ 

Projections in the hfted domain are no longer expressible in source code, precluding the 
possibility of using program transformation or the other techniques that are applicable to 
partial predicate typings. 

The use of program transformation techniques for program analysis is used in other 
approaches, like abstract compilation, but to our best knowledge, the application of the 
fold/unfold method of program transformation for program analysis is a novel idea. The 
only similar approach appears in ( Gallaghe r and Peralta 2000^ to develop a type inference 
system for Prolog, and (Comini et al. 2000j to verify program properties. 

There is also some existing work on using constraint generation for this kind of prob- 
lems. In ( Sekar and Ramakrishnan 1995 1, two degrees of definiteness are defined: normal 
form and head normal form, which leads to the notion of e-demand (normal form needed) 
and (i-demand (head normal form needed). Recursive equations for computing how these 
degrees of demand are propagated are generated for a given program, based on an oper- 
ational semantics. The authors also mention the possibility of using demand analysis for 
sequentiality recovery, although the idea is not developed there. 
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8 Open Issues and Future Work 

The importance of demandedness analysis goes beyond functional-logic languages. In (?) 
dependent demand patterns are used for the analysis of concurrent (constraint) logic lan- 
guages. 

The question whether program transformation tools can be used for program analysis 
following the techniques presented here is still open, although several problems appear. In 
the first place, deciding on the equality of functions is harder, in general, than checking the 
equahty of set expressions. Second, although the theory behind program transformation is 
well developed, practical implementations are scarce. However, this is an active area and 
we plan to study the possibility of adapting the tools by Vidal's group (IRamos et al. 20051 
to serve this purpose. 

Another possible extension of this work is to study the appUcation of partial predicates 
to other analysis problems, like groundness, etc. 

The extension of the analysis when higher order functions are used deserves an addi- 
tional discussion. In fact, some complications do appear if higher order definitions are 
introduced. Let us consider an example involving curried definitions. 
Take, for instance, the standard definition of the addition of Peano naturals of examplel2n 

An interesting property that we would like to express is the fact that the first argument 
must be evaluated to head normal form in order to get a result in head normal form. This 
is very simple for the noncurried form: plus : (hnfNat x any) hnfNat, but it is not 
clear at all how to express that for the curried version. In first place, (+) maps naturals to 
a new function, and it is not this function we are interested in, but the result of applying it 
to any other natural number. To grab the problem more formally, we will make use of the 
following lemma. 

Lemma 36 (Currying lemma) Let (/ o) denote Ax. f o x. Then, the following holds: 

curry (/og) = (/ o) o (curry g) . 

What we are looking for is a property of the form: (+) : hnfNat n and what we actually 
have is plus : (hnfNat x any) hnfNat . This is equivalent to: 

hnfNat o plus C (hnfNat X any) . 

As curry is continuous, we can curry both sides of the inequality: 

curry (hnfNat o plus) C curry (hnfNat X any) 

and using the lemma above: 

(hnfNat o) o (+) C curry (hnfNat X any) 

or equivalently 

(+) : curry (hnfNat X any) (hnfNat o) . 

Well, this gives essentially the same information as the demand typing for the noncurried 
version, but there is a problem: the functions in the typing are no longer partial predicates, 
i.e. they are not in the domain t — > Two. 
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There are essentially two ways of dealing with these problems in practice. One possibil- 
ity is to avoid higher order definitions as much as possible, translating curried versions to 
noncurried ones - and vice-versa with the results of the analysis. 

The other possibility is to generalize demand types to pairs of functions in the domain 
T —> t'. Although the theoretical interest of this lifting to higher order domains is apparent, 
and a higher order metalanguage seems feasible, the practical use will be very restricted, 
as the techniques in Section l4!2l will not be applicable. 

9 Conclusion 

We have presented a semantic framework for the denotation of demand properties, decou- 
pling it from its abstraction or any implementation detail of the analysis. In spite of defining 
a new language and an associated demand logic (cf. the strictness logic in (Benton 1992)), 
properties are expressed in the language under study and problem independent techniques 
are used as proof methods: equational reasoning or set constraint solving. 

The collection of analysis that can be modelled includes classic strictness analysis, 
Wadler's four point domain, etc. In particular it allows to describe demand analysis that 
is very important for the efficient implementation of several aspects of functional-logic lan- 
guages: efficient implementation of lazy narrowing ('Moreno-Navarro et al. 1 993IIMarino et al. 19931 . 
compilation of nonsequential programs (Marino and Moreno- Navarro 2000| or the lazy 
management of default rules JMoreno-Navarro 1996> . The formalism has been used to 
prove the correctness of a method based on set constraint solving, in a constructive way. 
It can also be used to generate domains suitable for abstract interpretation (uniform predi- 
cates). 

Furthermore, the formalism is quite intuitive as it resembles the language to reason about 
and uses program transformation techniques. We have also shown how polymorphism and 
higher-order properties can be managed - at least theoretically - in this framework, al- 
though the extension for the analysis of higher-order program presents some challenges. 

An original feature of this research is that it is completely based on a declarative (model 
theoretically) denotational semantics of the language, rather than on an operational one.'^ 
From a practical point of view, performing the analysis on operational data is often easier, 
but considering that the domain of properties can be understood in a purely declarative 
setting, we wanted to explore the possibility of performing the analysis without using a 
particular operational semantics. 

We also felt that the applications of set constraints to program analysis have been biased 
towards problems stated in an operational fashion, and that deriving set constraints from 
semantic equations was an original approach and a challenge worth taking up. 
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Appendix A Semantics of the Kernel Language 

The following lines describe a denotational presentation of a declarative semantics for 
the language used in this paper. We start providing a declarative, logical semantics. Let 
us define the semantic domains first. H is the cpo completion of the Herbrand universe 
formed with all the (data) constructors in a program. The (higher order) domain of values 
D is given as the least solution to the equation 

D^H+[D^^D^] + Yj[iCdi... di)\C e DC, Vk.dk g D] 

i 

Environments are type-preserving mappings from variable symbols to H, and interpreta- 
tions (for a given program) map every function symbol to a value in D: 

Em =VS^ H 
Int ^FS^D 

Environments can be lifted in the standard way to functions from terms (with variables) to 
H, with the usual overloading. We regard constructors as free, and thus their denotation is 
the usual, standard one. 

Definition 37 (Models) An interpretation / is a model of a ground instance 1' = b' r' 
of a defining rule I = b r iff 

Eini □ ElbJI ^ Elr'JI 

An interpretation is a model of a rule when it models all its ground instances: 

Vo-. E[[o-Z]]7 3 Elo-bil Ellcrrl/ 

being cr a well typed grounding substitution. An interpretation 7 is a model of a program P 
(in symbols 7 |= P) ifl" 7 is a model of every defining rule in P. 

Next we define a denotational construction for such a semantics. We will make use of the 
following semantic functions^*: 

F : Int 

R : Rule — > Int Int 
E: Exp^ Int D 

E is just recursive evaluation of expressions according to the semantics of the program, and 
can be defined as the homomorphic extension of the semantics for function symbols (F). 

It is needed in order to evaluate the right hand sides of rules. R is the interpretation trans- 
former associated with each rule of the program and represents the amount of information 
added by every possible apphcation of that rule: 

Rlfti...t„ = b^ rjl = Afs.ifs ^f)^Axi...x„.\_\(pti=xiA---Apt„=x„A E^bJI) ^ E^prJI 

p&Env 

Fp = m U (^IruleJ)) 

ruleeP 

Properly speaking, they all depend on the program - ¥p, Ep, etc. - but the subscript will be dropped when no 
confusion may arise. 
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The symbol (=) denotes strict equality and (■ — > ■) is shorthand for (■ ■\±). For every 
equational program P, Fp, R and E are continuous'^. 

The following result, proved in JMarino 2002> . states the adequacy of both presentations: 

Theorem 38 Let Rulesp(f) be the set of rules defining function symbol / in propgram P. 
For every functional-logic program P, and function symbol / e FSp, Fp f is the minimal 
model for the rules in Rulesp(f) . 

Appendix B Proof of Theoreml33l 

Theorem 1331 states the soundness of the analysis based on the solution of a set of con- 
straints. If S denotes the system of constraints generated from a given program applying 
the rules in Subsection l5.4l and cr is a solution of S , then for every variable d»f occurring 
in S the following must hold: 

The following is still very sketchy — a full proof would be much longer. Some lemmata 
on valid program transformations are necessary in order to justify the different rules for 
constraint generation: 

Lemma 39 The following program transformations are valid according to the semantics 
of the kernel language: 

1 . Any function symbol / defined by rules 

fti^bi ■■■ ft„^ b„ 

can be rewritten as 

/ = /.! •■■ /=/.« 

where 

/.I ti ^bi ■■■ f.n t„ = b„ 

2. Any program rule 

/(?!,...,?„) = r 

can be rewritten as 

fit) ^b^r* 

where b is a guard conveying all the matching information and r* is obtained from b re- 
placing every occurrence of a variable in the left hand side by an application of a selector 
function. In more detail, /(f i ,...,?„) = r is rewritten as 

/(f) - match{t\,t) A ■ • ■ A match(tn, t) — » 6(r, f) 

This is due to the operators involved in their definition. Observe that the lub in the right hand side of the 
definition of Ris not infinite because the conditional inside limits the possibilities to ± or EJcrrli - where o" is 
unique - and thus is well defined. 



Demand Analysis with Partial Predicates 



33 



where 

match(K, t) — isK(t) 
match{C{w\, . . . , Wm), = isC(t) A match{w\, f|i) A ■ ■ ■ A match(w,„, t\„,) 
match(x, t) — True 

and 

5(f(eu....ej),t) = meut\...,6{ej,t)) 
6(x,t) - proj (/?oi(x, f))(f) 

provided that proj(/?)(f) returns t\p and that posix, t) is the position where x occurs at t. 
3. Given a rule 

/(fi,...,f„) ^b-^r 
either r is a variable, or a constant, or it can be rewritten as 

f{t)^b^g{h{t),...,h„{t)) 

Moreover, this is true for the whole set of rules in a program, i.e. the newly introduced func- 
tion definitions - for h\,. . h,,, - can again be normalized and the whole transformation is 
terminating. 

Proof of Rule 1 (Main Function Constraint) From lemmal39l 1 , the definition of (u) and 
the semantics of the language, 

p o f — p o f.l U ■ ■ ■ U p o f.n 
for every partial predicate p and function symbol /. 

Proof of Rule 2 (Main Rule Constraint) This is one of the lossy steps. This is justified 
by a generic property of projections: if 

p e PP (ti X ■ ■ • X T„) 

then 

p\Z p\X---Xp„ 

so if f.i is a function on tuples 

p o f.i n{po f.i)i X ■ ■ ■ X (/? o /./)„ 

Proof of Rule 3 (Head Constraints) Given program rule 

/.i (fi,...,f„) = r,- 

we have to prove the inequation 

p»f.i.k c A{p,f,i.k,tit) 

and, in fact, we are going to prove the equality. Remember that p»f.pos is intended to 
represent the projection at position pos of p o f. From lemma|39l2, we have 

f.i(t) — match(ti,t) A ■ ■ ■ A match(tn, i) — > 5(r;, t) 
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so 

p o f.i(t) — match{t\, f) A • ■ • A match(t„, t) — > p(6(ri, f)) 
and from Def. [15] 

prjk(p o /./) Xk = p(f-i(xi, . . . , Xn)) True 

— match{tk, x) A ■ ■ ■ A p(6(ri, t))(x) 

where only Xk and its subterms contribute to the result. From the definition of A and 6 it 
can be proved that 

A(p, f, i.k, tk) Xk = prjkip o /./) xt 

Proof of Rule 4 (Body Constraints) In Sec. 15. 41 three cases were considered: 

1 . (The body is a variable) The inequality to prove is 

p»f.i.k c p 
provided that the rule for is of the form 

f.i(ti,...,t„) = X 

and that x occurs at position k at the head of the rule. 

From lemmal^2. we have that the definition of /./ can always be cast as: 

/./(f) = match(t\, f) A ■ ■ ■ A match(tn, t) — » proj(fe)(f) 

and then 

p o f.i{f) - match(ti, t) A ■ ■ ■ A match(tn, t) — » /?(pro j (fe)(f)) 

so 

prjk(p o f.i) Xk — match(ti,t) A ■ ■ ■ A match(t„,t) A p(xk) 

which is clearly less defined or equal than p, hence the inequality. 

2. (The body is a constant) The proof is very similar to that of the last case. 

3. (The body is a function application) Without loss of generality (see lemma l39l3). we will 
restrict ourselves to rules of the form 

f(t)^b^g(hi(t),...,hM) 

so 

(pof)(t)^b^(pog){hi(t),...,h„(t)) 

To show the correctness of the inequalities 

p-f.m c (p»g)„ 
p»f c p.f.lthi 



p»f £ p.f.m4im 
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we can proceed by reductio ad absurdum. As the P-f.i.j variables are only constrained by 
these inequalities, we can be sure that they will take the greatest values. The only possibiUty 
for the system to fail is that one inequality in the second set fails. Let z be an element such 
that z 6 (/? o /) and z. i (p-f.k4ii^) . Introducing z in the equation above for {p o f) leads to 
immediate contradiction. 

Proof of Rule 5 (Simplification) Trivial, as this is essentially replacement of equals by 
equals. 

Proof of Rule 6 (Weakening) Trivial as this is essentially replacement of a term by a 
greater one in the right hand side of "lesser than" inequation. 



